The present disclosure relates to computer runtime systems, and specifically composite applications implemented in computer runtime systems.
The process of building complex business logic using a set of components, such as portlets, can be a tedious endeavour. First, individual components are deployed sequentially. Then, the deployed individual components are arranged on a customer's staging system as desired. Finally, component interaction and access control are defined according to the business logic to be implemented. The above steps require active involvement of application developers, portal administrators and persons with the necessary business domain skills.
To simplify the aforementioned process, composite applications, such as composite portal applications (or portal server applications), were introduced as a key strategy for implementing meaningful business value within a Service Oriented Architecture (SOA). Composite portal applications provide a flexible framework to produce very complex websites with reasonable effort. The basic functional units of a composite portal application are application components (or portlets, when specifically referring to the functional units of a composite portal application). The composite portal application aggregates the output of the individual portlets to an output which can be rendered in a browser. This aggregation of content is an important feature of composite portal applications, since the composite portal application effectively integrates the user interface (UI) of independent portlets without the need to write any integration code.
Business analysts and application designers can leverage composite applications to assemble complex business logic easily from individual application components, such as JAVA® classes (JAVA® is a registered trademark of Sun Microsystems, Inc., portlets, Enterprise JAVA® Beans (EJBs) (EJB is a trademark or registered trademark of Sun Microsystems, Inc.), processes, Plain Old JAVA® Objects (POJOs), or other code artifacts. Portals expose a user to multiple services in a single interface. Composite applications allow the user to interact with these multiple services. Composite applications do away with multiple User Interfaces (UIs) and permit improved data connectivity. Composite applications achieve this by making functionality and data independent from an architecture. As a result, users can, on their own, define, create and manage composite portal applications. The use of a composite application delivery model emphasizes a move towards a strongly business-driven usage model with plug-ability and fewer dependencies on support by system administrators.
Modern composite portal applications typically have a considerable number of application components. Furthermore, application components can be added to an existing aggregation of application components to produce even more sophisticated composite applications. Each application component in the aggregation must be executable on the designated target system to which the composite portal application is deployed. One example of a target system is the JAVA® Platform, Enterprise Edition (J2EE), which provides a programming platform for developing and running distributed multi-tier architecture JAVA® applications. However, other target systems are conceivable as well. A complex composite portal application comprises manifold application component types, which are all suited together in a coherent composite application produced by a large application development team.
U.S. Published Patent Application US2006/0036993 A1 describes a system and method for developing a composite portal application by creating a portal application archive, and for automatically deploying the portal application archive into a portal server environment. A portal application is a specific type of application. In particular, a portal application is a collection of pages, portlets, policies, and roles. According to an embodiment of the method in accordance with the above mentioned document, a composite portal application is provided to a portal server environment as a portal application archive. The portal application archive includes (i) all application components in machine-readable code for forming the composite portal application, and (ii) an application component assembly descriptor in machine readable code that specifies how the application components need to be assembled such that the composite portal application is correctly deployed into the portal server environment.
In order to deploy the composite portal application into the portal server environment, the portal application archive is provided to a deployment mechanism within the portal server application environment. The deployment mechanism enables the deployment of the portal application archive into the portal server environment. Further, the application component assembly descriptor included in the portal application archive is evaluated by means of the deployment mechanism. The application components are automatically deployed into respective parts of the portal server application environment according to information included in the application component assembly descriptor.
The application component assembly descriptor can be implemented in the form of an Extensible Markup Language (XML) descriptor file and includes meta-data that describe how each particular application component of the composite portal application is to be used within the composite portal application. Each piece of meta-data is evaluated accordingly via the deployment mechanism described above. The meta-data provided by the application component assembly descriptor therefore provides added value for the composite application with respect to the standard JAVA® J2EE. While JAVA® supports coding, deployment, and life cycle aspects of composite portal applications, the meta-data can be regarded as comprising the logic focus description language on top of JAVA® and can be implemented in the form of XML.
However, there are several limitations to the current state of the art. First, the packaging of a composite application includes the implementation of the application components, as well as the component assembly descriptor. Second, a composite application needs to be developed for a specific target hardware and software platform. Thus, current implementations fail to provide a generic composite application package that can be installed, executed, and managed on various target platforms. There are several different target platforms/frameworks/runtime environments that require a particular instantiation of the composite application. Such target platforms/frameworks include, but are not limited to Rich Client (e.g., WebSphere® (WebSphere is a registered trademark of IBM) Everyplace Deployment (WED), which is based on Eclipse™ (a trademark of Eclipse Foundation) Application Programming Interfaces (APIs)), Portal Servers (e.g., WebSphere® Portal, which is based on portlet components and J2EE Portlet APIs), IBM Lotus Domino (e.g., Lotus Notes C/C++APIs), Microsoft .NET environment (Microsoft and .NET are trademark of Microsoft, Corp.), and Mobile Devices.
Moreover, the layout architecture and the runtime APIs against which the application components are implemented, differ greatly between target platforms. For example a Rich Client target platform requires application components to program against Eclipse APIs. In contrast, a Portal Server target platform requires application components to program against the J2EE Portlet APIs (e.g., according to JAVA® Specification Request (JSR) 168). Since each target platform has a different application component lifecycle management model, the application components require a different handler for each target platform to implement the application component's life cycle. Each target platform is expected to have the necessary handler pre-deployed. For instance, a Rich Client target platform exploits the Open Services Gateway initiative (OSGi) Alliance as an application component management model. Moreover, a Portal Server target platform is based on a WebSphere Application Server (WAS)/J2EE deployment frameworks.
Thus, during deployment/distribution of the composite application to the various target platforms, the application components only get installed on a specified target platform for which the packaged application components have been developed and the requisite handler has been pre-deployed to the target platform. This limitation prevents the same composite application from being installed on other target platforms that lack the requisite handlers.